LINE DEVELOPER DAY_2015 Tokyo「ビッグデータを活用するための分析プラットフォーム」レポート #linedevday

LINE DEVELOPER DAY_2015 Tokyo「ビッグデータを活用するための分析プラットフォーム」レポート #linedevday

Clock Icon2015.04.29

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

昨日は、LINE株式会社さんが開催されたイベントLINE DEVELOPER DAY_2015 Tokyoへ参加してきました。

Taichi Hashimotoさんが講演された「B-5: ビッグデータを活用するための分析プラットフォーム 〜データ集計した先に求められる分析技術」を聴きましたので、レポートします。

前半は、さまざまOSSを活用して構築された、社内の利用者のニーズに応じたデータ分析基盤の紹介でした。後半は、KPIを人間が見るのでなく、変化を自動検知して通知するシステムを開発中というお話でした。

以下、レポートです。

データ分析について

LINEにとってデータ分析とは何か

  • Collecting: データを集約する
  • Reporting: サービスの状況を的確に報告する
  • Analyzing: サービスの問題点や改善点を分析できるようになっている

この3つのことを実現するように技術や環境を提供している。

重要だと思うこと

  • Collecting
    • リーズナブルなデータの集約
    • 大量のデータを保持すること
  • Reporting
    • 柔軟なデータの集計
    • わかりやすいチャートでの可視化
  • Analyzing
    • 簡便で高速なデータの抽出

異なるニーズ

データの利用者によって、求めるものが異なる。

エンジニアの声
UIなんてどうでもいいから、生のデータを1箇所に集めて、自分たちがアクセスしやすいようにしたい。
プランナーの声
KPIを出してほしい。データはきれいなグラフで可視化されていることが望ましい。そしてExcelでダウンロードできることが非常に重要

プランナーはエンジニアよりもデータの加工を要望することが多い。これらをふまえて、どういった分析環境が必要か?

for エンジニア

エンジニアのためのデータ分析基盤

エンジニアに対しては、凝ったことをする必要はないと考えた。SQLなどのクエリを柔軟に発行できるようにする。(エンジニアが自由に実行する)APIによるバッチ処理と連携できるようにする。

次のようなツールを利用している。

  • Fluentd: 柔軟なログ収集を可能にするフレームワーク
  • Norikra: リアルタイム集計処理システム。ストリーミングデータ処理としてSQLが利用できる
  • Shibu / Shibu UI: Webベースのクエリツールとジョブスケジュール。Hadoopに集約されたデータを扱う。

データをHadoopに集約して、クエリが叩けるインタフェースからアクセスしてもらう。リアルタイム処理にはNorikraを使っている。

For プランナー

可視化、ダウンロード、No SQL(SQLを書かなくてもなんとかできるようにする)がポイント。

プランナーのためのデータ分析基盤

次のようなツールを利用している。

  • Hadoop: 大規模分散データ処理環境。構成は、HDFS, MapReduce, YARN
  • Hive: 大規模データに対するDWH
  • Presto: 分散データ処理エンジン。Hiveより高速処理できるのでBIツールのバックエンドに利用
  • Prestogres: BIとPrestoをつなぐコネクタ
  • InfiniDB: MySQLベースのカラム型分散DB。BIツールやクライアントツールから利用するデータを格納
  • IBM Cognos: Webベースのレポートオーサリングツール。ランキング変動のヒープマップなど、複雑で手作業で作ると大変なグラフや表を、それなりのコストで作成できるので利用している。
  • Pentaho: OLAP(Online Analytical Processing)型の多次元分析用システム

エンジニア用に集計したHadoopクラスタのデータを、さらにプランナー用に流し、Prestoを経由して確認できるようにした。

ソリューション

このように、冒頭で挙げた課題を解決している。

  • Collecting
    • リーズナブルなデータの集約 → fluentd
    • 大量のデータを保持すること → Hadoop
  • Reporting
    • 柔軟なデータの集計 → Hive / Shibu / Norikra
    • わかりやすいチャートでの可視化 → IBM Cognos, Pentaho
  • Analyzing
    • 簡便で高速なデータの抽出 → Presto, InfiniDB, Pentaho

重要視していること

上記のデータ分析基盤を構築、運用する上で、次の内容を重要視している。

  • API連携できるようにすること
  • OSSの採用。足りないものは自分たちで作ること
  • データをなるべく隠蔽すること。認証をしっかりした上で、ユーザ情報を見せる
  • ユーザトラッキングはしないこと。LINEのユーザは非常に多いため、1人のユーザをトラッキングしてもサービス改善に結びつかないと思っている。苦労が多いわりに利がないので、一切やっていない

分析プラットフォームの構成

グローバル化にともない、次のような課題が見えてきた。

サービスの変化
グローバル化、多様化に加えて、長寿化(サービスの延命)
人の変化
プランナーの増加

上記の変化を受けて何が起きるかというと、KPIがサービス × メジャー × ディメンジョンで爆発的に増加する。

サービスや人が変化した結果、起きること

国別、カテゴリ別などはもちろん、サービス運用を続けるうちに歴史的背景によるフラグが存在したり、人が増えることでいろいろな要望が出たりすることで、KPIが増加する。

KPIが増えると、忙しくなり、だれもKPIをつぶさに見なくなる。そして、サービス運営として何をすればよいかが、だんだんわからなくなってくる。

KPIの変化を人ではなく機械がみる

上記の対策としてチームで考えたのは、KPIを人間が見ずに、KPIの変化を伝えること。たとえば、数十ヶ国 × 数万個のスタンプのKPIを人手で見ると大変なので、自動化して、KPIに特徴的な変化が起きた時に、プランナーやエンジニアに通達する仕組みをつくる。

KPIモニタリングシステムの開発

KPIモニタリングシステムを絶賛開発中で、もう少しで運用をはじめようとしている。

  • すべてのKPIトレンド分析を自動化
  • 時系列でトレンドを学習して予測値を算出
  • 算出された値に対して、検出された値が異常かどうかをみる(ポジティブでもネガティブでも)
  • メールやチャットでアラートを伝達する

KPIモニタリングシステムの構造

プランナー用のシステムと別に、KPIのトレンド分析システムを設置する。これには、KafkaSparkを利用する。各KPIを時系列に並べ、Kafkaで予測値を算出する。実値を見て、通達すべきかそうでないかを判定し、処理をおこなう。

  • Timseries Producer: 次元ごとに分解してKafkaへ
  • Timseries Monitor: トレンドを学習してモデルを構築し、Kafkaに保存
  • Notification Monitor: 予測値よりも実値が大幅に異なる場合、通知する

まとめ

  • データ分析環境はHadoopをベースにして構築
    • OSSベースで、足りない部分や要望に合わない部分は自分たちで手をいれる
    • 認証を入れる(だれがどんなクエリを投げたか、監査ログをとるなど、データを保守的に扱う)
    • ユーザ情報(ユーザID)は重要でないのでなるべく隠蔽する
  • KPIモニタリングを強化
    • 増え続けるKPIを自動的に処理する仕組みをつくる

おわりに

「KPIの変化の通知を自動化する」という非常に興味深いお話でした。

システムのアクセス監視やパフォーマンス監視では、トレンド分析をするのですから、当然といえば当然の発想なのかもしれません。しかし、ビジネスのコアにかかわるロジックにも、それを適用するのがすごいですね。もちろん、発想を実装して実現されるLINEさんの開発者の方の技術力もすごいです。

「何を特徴的なデータと定義するか」が難しそうと想像しますが、そのあたりもLINEさんが得意とされている機械学習を活用して、早々に実現されるのかもしれません。いつか続きのお話をお聴きしたいなあと思いました。

それでは、また。

今回のイベントのその他のレポートは、こちらです。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.